Yet timing closure has a way of becoming a showstopper, and it can consume more resources than any of the more conventionally productive tasks in a design. Designs have been delayed for months, or even scrapped, because the front-end tools were unable to bring about predictable improvements in delays on critical nets.

Unfortunately, this is not an esoteric problem infesting bleeding-edge design teams. Timing closure is certainly harder with advanced processes, where the role of interconnect in delay looms greater than the role of loading. But the problem has been noted in designs using relatively mature processes.

The one area that might be assumed free of the problem is FPGA design. After all, the chips are already fabricated, the interconnect is often heavily buffered and, presumably, repeatable, and the vendor-supplied timing analysis tools are usually pretty good by all accounts. But talk to consultants who make their daily bread by stepping in to help on FPGA implementations, and you will hear the words again: timing closure.

This month, we offer a closer look at the problem and the way different design teams are approaching it. Our cover story comes to us from a hot design group in the wireless signal-processing sector. In signal processing, as in the microprocessor business, you can never go fast enough. So the ability to shave the safety margins on timing turns directly into faster chips and thence into market advantage.

The Morphics team reviews for us a comprehensive approach to timing closure that it has used successfully on an advanced process with a very challenging design. To summarize in a phrase, there is no silver bullet. For Morphics, the pursuit of timing closure starts with architectural planning and continues through partitioning, floor planning and implementation.

In our Working Papers item for this month, we hear a decidedly similar story from the design services group at Avnet. That team is focused on assisting customers with Xilinx FPGA designs. And its message is the same: no silver bullet, just consistent attention to detail and unrelenting use of best practices, seasoned with experience and some valuable rules of thumb.

It would have been great to print an article revealing how one particular tool made the problem go away. But today, that doesn't appear to be so. The issue is to organize the design so that the chances for big errors in timing estimation are isolated to a few nets, limited in extent and then gradually eliminated. That requires many members of the team to see the timing problem the same way, even though they are watching from different perspectives.

To offer another one-liner, the message seems to be that timing management comes down to methodology management and, in the end, people management. And that may be why it keeps folks up nights.